Distributed computing is a type of parallel processing in which different components of an application, i.e. software programs or hardware modules processing logic, run simultaneously on two or more computing device that communicate with each other over a network. An application component may make an invocation, communication, or call to another component running on a different computing device, requesting a certain function to be performed or certain data to be returned. These application components may operate in different computing environments, e.g. different hardware platforms, operating systems, and programming languages. For example, two software programs within a distributed application may be written in different programming language and executed on different operating systems running on different processors. It is often difficult for a developer to implement a call directly from one such application component to another if the two components are designed and operated within different and incompatible computing environments. Therefore, there must be a common communication medium to allow these application components to interoperate and interact with one another.
In a conventional distributed system processing a distributed application software, a middleware component referred to as an Object Request Broker (ORB) is used to enable software programs operating within different computing environments to communicate with one another over a network. An ORB transforms data structures from one computing platform to a sequence of bytes which can be transmitted over the network and received by another computing platform. At the receiving computing platform, the ORB transforms the sequence of bytes to data-structures understood by the receiving computing platform. The ORB also provides transparency to the programs running within the distributed system, so that a program resident on a computing platform within the ORB can communicate with another program resident on a remote computing platform, without needing to know the location of the program, the type of platform where the program is executed, or operating system that executes the program.
ORBs communicate with each other via an abstract protocol referred to the General Inter-ORB Protocol (GIOP). The GIOP defines the format of data and syntax of messages transported through the network. The standards associated with the GIOP are maintained by the Object Management Group (OMG). The OMG also defines an architectural model of a distributed system referred to as the Common Object Request Broker Architecture (CORBA). For every application component within the distributed system, CORBA creates a bundle containing information about the capabilities of the logic inside and how to invoke it. CORBA uses an Interface Definition Language (IDL) to describe the interfaces that objects present to the world. The IDL describe an interface in a language-neutral way, so that software components that do not share a common programming language or compilation platform can communicate with one another. CORBA also defines a mapping for different programming languages such as Ada, C, C++, or Java, to communicate with the IDL.
A simplified model of a CORBA system is discussed with reference to FIG. 1. In this figure, the network 110 delivers a request from a client computer 120 to a server computer 130. An ORB Repository (not shown) stores a list of all objects, such as object X, available for execution on all computers on the network 110. The Client ORB 110 may access the ORB Repository and provides the client computer 120 with information about all objects, such as object X, executable through the ORB. In this example, the object X includes a method “fire”. Although the object X is stored in and is executed by the server computer 130, that code is completely transparent to program 122 on the client computer 120. The program 122 need not know the programming language used by the program 132 or the operating system running on the server computer 130. Thus, from the perspective of the program 122, it makes a call to object X the same way as it would call any local object.
The program 122 may invoke the object X to perform the method “fire” by sending this request to client ORB 124, which provides an interface for object X to the computer 120. The client ORB 124 uses the IDL stubs 126, which are pre-compiled from IDL and define how the client computer 120 can invoke the object X on server computer 130. There is an IDL stub for each interface that the client computer 120 uses on another computer on the network 110. The client ORB 124 includes code to perform marshalling, meaning it encodes the operation and its parameters into flattened GIOP message format that is can send through the network 110 to the server computer 130.
At the server computer 130, the IDL skeletons 134 provide the static interfaces to each service exported by the server. These skeletons, like the stubs on the client computer 120, are created using an IDL compiler. Using these skeletons, the server ORB 134 transforms the flattened GIOP messages into operations and parameters understood by the object X in the sever computer 130. Thereafter, the object X executes the desired operation and, if necessary, returns the requested data back to the client computer 120 through the ORB.
Conventional ORB models have been in use in distributed software systems for years. In recent years, ORB software has been developed that can run on a microcontroller or a digital signal processor (DSP). An application may, however, be developed directly as a hardware component such an Application-Specific Integrated Circuit (ASIC)— an integrated circuit customized for the particular purposes of the application. Alternatively, an application may be implemented in a programmable logic device that does not implement a fixed function, but instead consists of a sea of logic gates and connection resources that can be configured to perform a desired function.
A popular programmable semiconductor device used today is a Field Programmable Gate Array (FPGA), which is a device containing programmable logic components and programmable interconnects. The logic and interconnect components of the FPGA can be programmed by a logic designer to perform a desired functionality. An FPGA is slower than its ASIC counterpart, consumes more power, and may be unfit for very complex applications. However, an FPGA provides certain advantages over an ASIC, which include the ability to reprogram at will, a shorter time to market, the ability to fix bugs, and lower Non-Recurring Engineering (NRE) costs.
In order for hardware components such as ASICs, PLDs, and FPGAs to be effectively incorporated into a distributed system, they need to be equipped with an ORB interface capable of transforming software requests into signals understood by the hardware components. Likewise, the hardware must be capable of generating requests understood by the software components. A conventional method of connecting hardware device to distributed system is through a custom proxy operating on a General Purpose Processor (GPP) or a Digital Signal Processor (DSP) that provides an interface between the hardware device and a software-implemented ORB. This approach has the significant disadvantage of creating a performance bottleneck in the GPP proxy.
Alternatively, the hardware designers may implement a custom application-specific ORB module within the hardware device. However, this method requires hardware designers to understand CORBA as well as Object Oriented Programming—areas that many hardware designers are not familiar with. Also, an ORB module custom-designed for a particular application block may not be readily reusable, since code mapping would have to be embedded within the module for the particular application.
U.S. Patent Application No. 2005/0108382 to Murotake et al. discusses implementing an ORB on an FPGA within a Reconfigurable Communications Architecture (RCA) radio system. This publication, however, does not disclose how an ORB is to be implemented.
An Integrated Circuit ORB (ICO), developed by PrismTech Ltd., offers an embedded ORB written in portable VHDL that can be mapped onto on an FPGA. The ICO consist of an ICO engine, an IDL to VHDL code generator, the Spectra Modeling Tool, and the SCA (Software Communication Architecture) component. The SCA is an architecture framework that defines how hardware and software elements communicate within a software defined radio. An ICO engine is responsible for implementing the transfer syntax used by CORBA. The engine demarshals the incoming GIOP messages and extracts header and data fields from the messages. For the incoming messages, the engine performs operation name demultiplexing to determine which object the data in the GIOP message is being transferred to. Message data is then extracted by the engine to transfer to the appropriate FPGA logic block. If a reply is requested, the engine will perform a read operation to an object to obtain the necessary data for the reply. It also populates the header field and builds a reply message to in compliance with the GIOP standard.
Although the ICO allows for FPGA applications to communicate through an ORB, there exists a need to provide a better mechanism for allowing hardware implemented applications to communicate with each other in a more robust fashion.
Moreover, the ICO presents a disadvantage for FPGA developers. In the ICO, the ICO engine must know of the location and functions of each application module in order to extract the appropriate header from the messages and perform operation name demultiplexing and data routing to the appropriate objects. The ICO IDL-to-VHDL code generator generates configuration parameters needed by the ICO engine. This code generator also adds these parameters to VHDL package files that configure the physical aspects of the ICO interface and internal storage elements. Therefore, parts of the VHDL code for the ICO's ORB core are generated at compile time by the code generator. As a result, if the FPGA designer wishes to reconfigure the functionality of an application block within the FPGA, the entire ORB module must be also be reconfigured and regenerated. This may be problematic to many FPGA designers in that it precludes the ability to partially reconfigure the FPGA without affecting the operation of the ORB and other FPGA modules.